64B/66B is a line code that transforms 64-bit data to 66-bit line code to provide enough state changes to allow reasonable clock recovery and facilitate alignment of a data stream at a receiver. The overhead of 64B/66B encoding (also referred to herein as 66B encoding) is 2 overhead bits for every 64 raw bits transmitted or 3.125%. This is considerably more efficient than the 25% overhead of the previously used in the 8B/10B encoding scheme which essentially charges every 8 bits of source data with a 2 bit (or 25%) overhead. Various protocols use 66B encoding such as, without limitation, Ethernet, Fibre Channel, InfiniBand, CPRI, etc. There are various applications in these protocols that require the relative phase relationship between different signals to be maintained across a transport network. An example application where the relative phase relationship must be maintained is in the financial industry where network services (e.g., Ethernet) are provided to high-frequency traders to connect to a stock exchange. To ensure fairness, the latency of each network service sold must be the same. Another example in Fibre Channel is trunking of Interswitch links (ISL) which requires the propagation delay of each ISL member be the same in order for the trunks to form. Various other examples are possible including Service Layer Agreements (SLAs) and the like.
66B encoded signals can be carried over another transport network protocol. An example such a transport network protocol is OTN, but other protocols are also contemplated (e.g., SONET, SDH, FlexE, etc.). The transport network protocol can introduce phase variations between signals. For example, OTN can be used to transport multiple 10 Gigabit Ethernet (10 GbE) signals on the same optical tributary signal between end user locations. However, OTN does not provide the ability to maintain the relative phase (and therefore latency or propagation delay) between OPUk payloads. On the contrary, an OTN mapper (circuitry) introduces delay skew between the OPUk payloads because of the delay uncertainty of its elastic stores. For conventional OTN equipment to support time/phase sensitive applications, the depth of the elastic stores must be tightly controlled.
However, controlling the depth of elastic stores in an OTN network is a complex task. First, due to the gaps in the data stream for the OTN overhead, the fill level of the elastic store is a noisy metric. This makes it difficult to produce a meaningful comparison between fill levels from different elastic stores. Second, when multiple stages of OTN mapping are used, there may be multiple inline elastic stores in the data path, each of which needs to be controlled. Third, if the mapped client signals take different paths through the OTN network, they may experience different delays that cannot be compensated by controlling the delay through the elastic stores alone.